Fault signaling for ethernet

ABSTRACT

A method may include receiving a message from a first Ethernet interface in a second Ethernet interface, wherein the message includes a first attribute indicative of an Ethernet service at the first interface according to a first operation, administration, or management (OAM) protocol. The method may further include mapping the first attribute to a second attribute, wherein the second attribute is in accordance with a second OAM protocol different than the first OAM protocol. The method may further include performing an operation at the second interface based on the second attribute.

BACKGROUND

In recent years, carrier-class Ethernet has emerged as a significanttechnology with respect to transport of traffic over Metro Area Networks(MANs). For example, in the United States, the demand for Ethernetservices is expected to increase at a compound annual growth rate (CAGR)of over 20%. The demand is projected to exceed $5 billion by 2012. Suchgrowth and increasing demand are partly driven by the need for higherbandwidth for site-to-site and data center connectivity, scalability,performance, and security.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B illustrate an exemplary network including two Ethernetinterfaces with fault signaling;

FIG. 2 shows an exemplary network employing Ethernet interfaces, such asa user-to-network interfaces (UNIs);

FIG. 3 is a block diagram of exemplary components of the UINI of FIG. 2;

FIG. 4 is a block diagram of additional exemplary UNIs;

FIG. 5A is a block diagram of exemplary functional or structuralcomponents of an interface of FIGS. 1A and 113;

FIG. 5B is a block diagram of exemplary components of a computingmodule;

FIG. 6 is a block diagram of exemplary functional components of themanagement plane of FIG. 5A;

FIG. 7 is a block diagram of exemplary functional components of thecontrol plane of FIG. 5A;

FIG. 8A through 8C are diagrams of exemplary mapping tables;

FIG. 9A is a block diagram of an exemplary operation, administration,and maintenance (OAM) protocol data unit (PDU) according to the Y.1731standard;

FIG. 9B is a block diagram of an exemplary type field of a client signalfault (CSF) PDU of FIG. 9A; and

FIG. 10 is a flowchart of a process for signaling faults from oneinterface to another interface.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements. The following detailed description does not limitthe invention, as claimed.

FIG. 1A is a block diagram of an exemplary network including a near-endEthernet interface 102 and a far-end Ethernet interface 104. In thisexample, an Ethernet service attribute (e.g., error condition) may bedetected at interface 102 (e.g., using an operation, administration, andmanagement (OAM) protocol). This attribute may be communicated tofar-end interface 104 over link 106 via the TelecommunicationStandardization Section of the International Telecommunication Union(ITU) Y.1731 (February 2008), Amendment 1 (July 2010). Link 106 mayinclude a point-to-point Ethernet connection and/or an Ethernet VirtualChannel (EVC).

In particular, a client signal fail (CSF) protocol data unit (PDU) mayinclude a three-bit Type field that can signal a client loss of signal(LOS), a client forward defect indication (FDI/AIS), a client remotedefect indication (RDI), or a client defect clear indication (DCI). TheCSF-PDU may be communicated from the near-end interface 102 to thefar-end interface 104. This limited number of types, however, does notsufficiently describe attributes in a way such that interface 104 mayappropriately act based on what is actually occurring at interface 102.For example, if a LOS is signaled from interface 102 to interface 104,interface 104 may shutdown, which may not be a necessary response inview of the actual conditions that caused the LOS attribute.

Further, interface 102 may employ a different OAM protocol thaninterface 104. In this case, the current ITU Y.1731 standard cannotcommunicate information generated from one OAM protocol from interface102, across link 106, to interface 104 employing another OAM protocol.

FIG. 1B is a block diagram of an exemplary network including near-endEthernet interface 102 and far-end Ethernet interface 104. In thisembodiment, link 106 may signal OAM attributes (e.g., faults) frominterface 102 to interface 104. In embodiments described below, thefault signaling may allow for information or attributes generated by oneOAM protocol at interface 102 to be transmitted to interface 104.Further, if interface 102 and interface 104 employ different OAMprotocols, the different attributes from the different OAM protocols maybe translated or mapped from one to the other. Thus, interface 104 mayact appropriately to attribute information provided by interface 102.For example, interface 104 may stop transmitting information tointerface 102 rather than shutting down the interface altogether.

FIG. 2 shows an exemplary network 200 in which interface 102 andinterface 104 may be implemented. As shown, network 200 may includeservice provider network 202, network 204, user to network interfaces(UNIs) 206-1 through 206-4 (collectively herein referred to as UNIs 206and individually as UNI 206), and network devices (NDs) 208-1 and 208-2(collectively network devices 208 and individually network device 208).Depending on the implementation, network 200 may include may includeadditional, fewer, or different networks and network elements than thoseillustrated in FIG. 2. For example, in one implementation, network 200may include metro Ethernet networks (MENs), network-to-networkinterfaces (NNIs) between the MENs, Synchronous Optical Network (SONET)network rings that are interconnected by long-haul optical lines,additional network elements (e.g., routers, switches, etc.), servers,client devices, wireless devices, etc.

Service provider network 202 may include optical fibers/non-opticallines and central office hubs that are interconnected by thefibers/lines. The optical fibers and the lines may form the backbone ofservice provider network 202. The central office hubs may providetelecommunication services to subscribers, such as telephone service,access to the Internet, cable television programs, etc., via lineterminals. Each central office hub may house telecommunicationequipment, including switches (e.g., Ethernet switches), optical lineterminals, etc.

Network 204 may include a wired or wireless network via which devicescommunicate (e.g., a fiber-optic network, a local area network (LAN), awide area network (WAN), a wireless LAN, a metropolitan area network(MAN), a cellular network, a public switched telephone network (PSTN),an intranet, the Internet, a satellite-based network, any other network,or a combination of networks).

Each UNI 206 may include a physical interface that is a demarcationpoint between a subscriber and a service provider. UNI 206 is typicallyprovided by a service provider/carrier and may be capable of supportingone or more bandwidths, such as 10 Mbps, 100 Mbps, 1 Gbps, 10 Gbps, etc.

In FIG. 2, one UNI (e.g., UNI 206-1) may form an Ethernet virtualcircuit (EVC) over network 202 with another UNI (e.g., UNI 206-2). UNIsthat form an EVC may communicate with one another over the EVC. UNIs mayform different types of EVCs, such as a point-to-point EVC, multipointto multipoint EVC, point to multipoint EVC, etc. Multiple EVCs may bebundled within a UNI or multiplexed on the same UNI. Each EVC may carrya single Class of Service (CoS) channel, or alternatively, carrymultiple channels of different CoSs (e.g., Ethernet Virtual Private Line(EVPL)-Real Time (RT), EVPL-basic (B), EVPL-Priority Data (PD), etc.).

Each network device 208 may include switches, routers, and/or othernetwork devices. Some of these devices may provide support for Ethernetservices (e.g., Cisco 6509 Switch).

FIG. 3 is a diagram of exemplary components of UNI 206. As shown, UNI206 may include a customer edge (CE) device 302 and a network interfacedevice (NID) 304. Depending on the implementation, UNI 206 may includefewer, additional, or different devices than those illustrated in FIG.3. For example, in one implementation, UNI 206 may include only NID 304.In another implementation, UNI 206 may include CE device 302, NID 304,and an Ethernet switch.

CE device 302 may provide an entry/exit to/from customer network, andtypically may be located in a customer's premises (e.g., office,apartment, house, etc.). CE device 302 may include interface 102 orinterface 104, for example, Examples of CE device 302 include a router,modem, firewall, etc. In FIG. 3, CE device 302 may provide thecustomer-side functions of UNI (UNI-C).

NID 304 may include a device that provides a service provider/carrier'sfunctions of UNI. In a different implementation, NID 304 may provide forother functions that are associated with a UNI. NID 304 may includeinterface 102 or interface 104, for example. Examples of NID 304 includetelephone network interface (TNI), optical network terminal (ONT),wiring terminals, etc.

FIG. 4 is a diagram of an exemplary point-to-point EVC 400. As shown,point-to-point EVC 400 may include UNI 404 and UNI 406. In apoint-to-point EVC (also called E-Line), one UNI may connect directly toanother UNI. UNI 404 may include interface 102 or interface 104. UNI 406may include interface 102 or interface 104. In some implementations, apoint-to-point EVC may include an Ethernet private line (EPL), and inother implementations, may include Ethernet Virtual private line (EVPL).

FIG. 5A is a block diagram of exemplary functional and/or structuralcomponents of network elements of FIGS. 1A, 1B, 2, 3, and/or 4. Networkelement 510 may represent UNI 1206, network device 208, a device innetwork 202 or 204, a device or component in UNI 206 or in networkdevice 208. As shown in FIG. 5A, network element 510 may include amanagement plane 512, data plane 514, and control plane 516. Dependingon the implementation, network element 510 may include additional,fewer, or different components than those illustrated in FIG. 5A. Forexample, in some implementations, network element 510 may not includecontrol plane 516.

Management plane 512 may include hardware and/or software components forsupporting operation, administration, and management (OAM) functions.For example, management plane 512 may support discovery, remote failuredetection/indication, remote loopback testing, alarm generation orprocessing, link performance monitoring, management information base(MIB) data retrieval, etc.

Data plane 514 may include hardware/software components for processingdata. In some implementations, such as routers, data plane 514 mayforward data to their destinations in network 200. Examples of dataplane 514 may include an Ethernet card, line card of a router, packetprocessing engine on the line card, forwarding information base (FIB),etc.

Control plane 516 may include hardware/software components forexchanging signaling information between a network device 510 andanother network element. This information may include routinginformation in accordance with a specific protocol, traffic engineeringinformation, etc.

Network devices shown in FIGS. 1A, 1B, 2, 3, and/or 4 may each includeone or more computing modules (e.g., each plane in network device 510may include a computing module). FIG. 5B is a block diagram of exemplarycomponents of a computing module 517. Computing module 517 may include abus 518, processing logic 520, a communication interface 550, and amemory 560. Computing module 517 may include other components (notshown) that aid in receiving, transmitting, and/or processing data.Moreover, other configurations of components in computing module 517 arepossible.

Bus 518 may include a path that permits communication among thecomponents of computing module 517. Processing logic 520 may include anytype of processor or microprocessor (or families of processors ormicroprocessors) that interprets and executes instructions. In otherembodiments, processing logic 520 may include an application-specificintegrated circuit (ASIC), a field-programmable gate array (FPGA), etc.

Communication interface 550 may include a transceiver that enablescomputing module 517 to communicate with other devices or systems.Communication interface 550 may include a transmitter and/or a receiver.Memory 560 may store, among other things, information and instructions(e.g., applications and an operating system) and data (e.g., applicationdata) for use by processing logic 520. Memory 560 may include a randomaccess memory (RAM) or another type of dynamic storage device, aread-only memory (ROM) device or another type of static storage device,and/or some other type of magnetic or optical recording medium and itscorresponding drive (e.g., a hard disk drive).

Computing module 517 may perform the operations described herein inresponse to processing logic 520 executing software instructions storedin a computer-readable medium, such as memory 560. A computer-readablemedium may include a physical, logical, tangible, and/or non-transientmemory device. The software instructions may be read into memory 560from another computer-readable medium or from another device viacommunication interface 550. The software instructions stored in memory560 may cause processing logic 520 to perform processes that aredescribed herein.

FIG. 6 is a block diagram of exemplary components of management plane512 of network element 510. As shown, management plane 512 may includeOAM logic 602. Although management plane 512 may include additionalcomponents, other components are not illustrated for simplicity. Inaddition, depending on the implementation, a single functional block inFIG. 6 may be implemented as multiple blocks or components.

OAM logic 602 may determine the attribute (e.g., status, health, OAMattributes, etc.) of Ethernet services (e.g., delivered by managementplane 512). Such OAM attributes may include layer one and/or layer 2attributes, for example. OAM logic 602 may determine the OAM attributeaccording to a management plane protocol. For example, OAM logic 602 mayemploy Link Aggregation Control Protocol (LACP) or Link-OAM (L-OAM) asdefined in IEEE 802.3-2008, part 5 (IEEE 802.3ah). In this example,L-OAM may indicate a “link fault,” a “dying gasp,” and/or a “criticalevent.” A “link fault” may indicate that the physical layer hasdetermined that a fault has occurred in the receive direction of networkelement 510. A “dying gasp” may indicate an unrecoverable local failurecondition (e.g., as defined by the manufacturer of network element 510)has occurred. A “critical event” may indicate that a critical event(e.g., as defined by the manufacturer or network element 510) hasoccurred. What is meant by “critical event,” “link fault,” “dying gasp,”may be specific to the manufacturer or the model of network element 510.

As another example, OAM logic 602 may employ E-LMI as defined by theMetro Ethernet Forum (MEF) 16. In this example, E-LMI may indicate theaddition of an EVC, the deletion of an EVC, the availability state of aconfigured EVC (e.g., active, not active, or partially active), or otherattributes of a UNI or an EVC.

FIG. 7 is a block diagram of exemplary functional components of controlplane 516 of network element 510. As shown, data plane 514 may includeattribute mapping logic 702 and extended Y.1731 logic 704. ExtendedY.1731 logic 704 may include an OAM logic 706 and an extended ETH-CSFPDU logic 708 (PDU logic 708). Although data plane 514 may includeadditional components, such as a processor, network interface, etc., forsimplicity, they are not illustrated in FIG. 7. In addition, dependingon the implementation, two or more functional blocks in FIG. 7 may becombined into one, or a single functional block in FIG. 7 may beimplemented as multiple blocks or components.

As mentioned above, mapping logic 702 in near-end interface 102 may mapa near-end OAM attribute into an intermediate attribute (e.g., accordingto a mapping table) for a message that is transmitted to a far-endinterface. Further, mapping logic 702 in far-end interface 104 may mapan OAM attribute in a received message into a far-end OAM attribute(e.g., according to a mapping table). Exemplary mapping tables aredescribed below in more detail with respect to FIGS. 8A-8C.

OAM logic 702 may determine the attribute (e.g., status, health, OAMattributes, etc.) of Ethernet services (e.g., delivered by data plane512). Such OAM attributes may include layer one and/or layer 2attributes, for example. OAM logic 702 may determine the OAM attributeaccording to a data plane protocol. For example, OAM logic 702 mayemploy Y.1731. In this example, the Y.1731 protocol may determine anattribute of LOS, FDI/AIS, RDI, or DCI.

Extended ETH-CSF PDU logic 708 may generate a PDU for signaling OAMinformation from near-end interface 102 to far-end interface 104. Inthis respect, PDU logic 708 may include a three-bit Type field that cansignal LOS, FDI/AIS, RDI, or DCI. In one embodiment, PDU logic 708 mayalso employ a Type field that is larger than three bits to signaladditional information, In one embodiment, PDU logic 708 may generate aCSF-PDU that includes a TLV fields (type-length-value). In this case, avalue field may specify information about attributes or include theattribute itself. FIG. 9A, discussed below, includes information aboutgenerating a CSF-PDU.

FIGS. 8A-8C are diagrams of exemplary mapping tables 800, 810, and 820in one embodiment. As shown in FIG. 8A, mapping table 800 is an exampleof a mapping table that may be used by two interfaces employing IEEE802.3ah (e.g., L-OAM), for example. Mapping table 800 may include anear-end OAM attribute field 802, a intermediate OAM attribute field804, and a far-end OAM attribute field 806. In one embodiment, mappingtable 800 may be stored in or used by mapping logic 702.

Near-end OAM attribute field 802 may include information indicative ofthe OAM attribute determined by OAM logic 602. As discussed above, OAMlogic 602 may employ LACP, L-OAM, or E-LMI, etc., for example, todetermine a near-end OAM attribute. As shown in field 802, possiblenear-end OAM attributes may include “link fault,” “dying gasp,”“critical event,” and “event condition.”

Intermediate OAM attribute field 804 may include the OAM attributes, forembedding into a message, that correspond to the near-end OAM attributeslisted in field 802. For example, according to field 804, anintermediate attribute of “link fault” corresponds to “link fault”attribute in field 802. An intermediate attribute of “dying gasp”(indicated in field 804) corresponds to “link fault” attribute in field802. An attribute of “critical event” (indicated in field 804)corresponds to “critical event” attribute in field 802. An attribute of“event condition” (indicated in field 804) corresponds to “eventcondition” attribute in field 802.

Far-end OAM attribute field 806 may include the OAM attributes thatcorrespond to an OAM protocol understood by, for example, far-endinterface 104. For example, according to field 806, attribute of“critical fault” corresponds to an intermediate OAM attribute of “linkfault,” “dying gasp,” “critical event,” or “event condition.”

As mentioned above, mapping table 800 may be used, for example, by anear-end interface and a far-end interface that both employ IEEE802.3ah. In this example, the near-end interface may store fields 802and 804, while the far-end interface may store fields 804 and 806. Inanother embodiment, the near-end interface and the far-end interface maystore all three fields. Further, the mappings shown in FIG. 8A areexemplary and other mappings are possible.

Mapping table 810, shown in FIG. 8B, is an exemplary table that may beused by a near-end interface that employs IEEE 802.3ah and a far-endinterface does not employ IEEE 802.3ah. Mapping table 810 includes anear-end OAM attribute field 812, an intermediate OAM attribute field814, and a far-end OAM attribute field 816.

The type of information stored in field 812 may be similar to the typeof information stored in field 802. Likewise, the information stored infield 814 may be similar to the type of information stored in field 804and the information stored in field 816 may be similar to the type ofinformation stored in field 806. Far-end OAM attribute field 816 maystore different information than field 806 because, in this example, thefar-end interface does not employ IEEE 802.3ah. In this example, anintermediate attribute of “link fault” corresponds to a far-end OAMattribute of “LOS” in field 816. Further, an intermediate attribute of“dying gasp” corresponds to a far-end attribute of “LOS.” Anintermediate attribute of “critical event” or “event condition”correspond to a far-end OAM attribute that may be defined by theadministrator, manufacturer, or operator. In this embodiment, near-endinterface 102 may store the information in fields 812 and 814. Far-endinterface 104 may store the information in fields 814 and 816. In otherembodiments, both interfaces may store the complete table 800.

Mapping table 820, shown in FIG. 8C, may be used, for example, by anear-end interface that does not employ IEEE 802.3ah and a far-endinterface that does employ IEEE 802.3ah. Mapping table 820 includes anear-end OAM attribute field 822, an intermediate OAM attribute field824, and a far-end OAM attribute field 826.

The type of information stored in field 822 may be similar to the typeof information stored in field 802. Likewise, the information stored infield 824 may be similar to the type of information stored in field 804and the information stored in field 826 may be similar to the type ofinformation stored in field 806. Near-end OAM attribute field 822 maystore different information than field 802 because, in this example, thenear-end interface does not employ IEEE 802.3ah. Rather, in thisexample, the near-end interface only employs Y.1731. In this example, anattribute of LOS may be detected, as indicated in field 822. Anintermediate attribute of “LOS,” defined in field 824, corresponds to anear-end OAM attribute of “LOS” in field 826. An intermediate attributeof “critical event” or “event condition” corresponds to a far-end OAMattribute that may be defined by the operator, manufacturer, oradministrator.

As indicated above, messages may carry attributes (e.g., fault signals)from interface 102 to interface 104, FIG. 9A is a block diagram of anexemplary message 900 in one embodiment. Message 900 may be an OAM PDU.Message 900 may include an MEL field, a Version field, an OpCode field,a Flags field 904, a TLV Offset field 905, a value field 902, and an endTLV field 907. The version field and OpCode field may includeinformation as defined, for example, in Y.1731.

In one embodiment, as shown in FIG. 9B, flags field 904 may include areserved field, a Type field 906, and a period field. Reserved field andPeriod field may include information as defined, for example, in Y.1731.Type field 906 may include information indicative of an OAM attribute,such as those specified in fields 804, 814, and/or 824). For example,Type field 906 may include a 16-bit field that specifies 65,536different possible OAM attributes.

TLV Offset field 905 may include information that specifies the type andlength, for example of value field 902. End TLV field 907 may indicatethe end of value field 902. In one embodiment, value field 902 mayinclude information indicative of an OAM attribute, such as theattributes specified in fields 804, 814, and/or 824.

FIG. 10 is a flowchart of a process 1000 for transmitting OAM attributesfrom one Ethernet interface to another Ethernet interface. Process 1000is described with respect to FIG. 1B, in which a fault signal is passedfrom near-end interface 102 to far-end interface 104. As shown in FIG.10, process 1000 may begin with the determination of OAM attributes(block 1002). OAM logic 602 in management plane 512 may employ LACP,L-OAM, or E-LMI to detect the status (e.g., attributes) of near-endinterface 102. For example, OAM logic 602 may employ L-OAM of IEEE802.3ah to determine whether there is a “link fault,” “a dying gasp,” a“critical event,” or an “event condition.”

The OAM attributes may be mapped into OAM attributes for a message to betransmitted to another interface (block 1004). Using mapping table 800,for example, a link fault error (field 802) may be mapped into anotherlink fault message (field 804) for transport over link 106 to far-endinterface 104. The intermediate OAM attributes may be encapsulated intoan Ethernet message (block 1006). For example, the OAM attribute messagemay be encoded into field 902 of packet 900. In another embodiment, theOAM attribute message may be encoded into field 906 (e.g., an extended16 bit Type field). The message with the attributes may be transmittedto another Ethernet interface (block 1008).

The far-end Ethernet interface receives the message and extracts theattributes (block 1010). For example, interface 104 may receive themessage over link 106 and extract the attribute (e.g., link fault). Thereceived attributes may be mapped into near-end OAM attributes (block1012). For example, using mapping table 800, a “link fault” attribute(field 804) is mapped into a “critical event” attribute (field 806). TheEthier interface may act on the near-end OAM attributes (block 1014). Inthe current example, interface 104 may act on the information in afashion appropriate for interface 104. The action may be short ofshutting down interface 104 (e.g., not transmitting signals to interface102), and may include sending an alarm, recording error status, etc.

In the above example, interface 104 included fields 804 and 806 of table800, indicating that interface 104 included IEEE 802.3ah signaling. Inanother embodiment, interface 104 may not include such signaling.Instead, interface 104 may use fields 814 and 816 of mapping table 810.In this case, the “link fault” attribute may be mapped into a “LOS”attribute in interface 104. If the message from interface 102 included a“critical event” attribute or an “event condition” attribute, thenfields 814 and 816 indicate that the attributes in these messages may bemapped to an operator-dependent OAM attributes. Thus, the manufacturerof interface 104 (or the administrator of interface 104) may program theattribute and actions accordingly.

Certain features described above may be implemented as “logic” or a“unit” that performs one or more functions. This logic or unit mayinclude hardware, such as one or more processors, microprocessors,application specific integrated circuits, or field programmable gatearrays, software, or a combination of hardware and software.

No element, act, or instruction used in the description of the presentapplication should be construed as critical or essential to theinvention unless explicitly described as such. Also, as used herein, thearticle “a” is intended to include one or more items. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

In the preceding specification, various preferred embodiments have beendescribed with reference to the accompanying drawings. It will, however,be evident that various modifications and changes may be made thereto,and additional embodiments may be implemented, without departing fromthe broader scope of the invention as set forth in the claims thatfollow. The specification and drawings are accordingly to be regarded inan illustrative rather than restrictive sense.

What is claimed is:
 1. A method comprising: receiving a message, from afirst Ethernet interface, in a second Ethernet interface, wherein themessage includes a first attribute indicative of an Ethernet service atthe first interface according to a first operation, administration, ormanagement (OAM) protocol; mapping the first attribute to a secondattribute, wherein the second attribute is in accordance with a secondOAM protocol different than the first OAM protocol; and performing anoperation at the second interface based on the second attribute.
 2. Themethod of claim 1, comprising: determining, at the first interface, athird attribute indicative of the Ethernet service at the firstinterface according to the first OAM protocol; and mapping the thirdattribute to the first attribute according to an intermediate OAMprotocol.
 3. The method of claim 1, further comprising: encoding thefirst attribute indicative of an Ethernet service at the first interfaceinto the message; and transmitting the message from the first interfaceto the second interface.
 4. The method of claim 3, wherein the first OAMprotocol includes a management plane protocol, wherein encoding andtransmitting includes encoding and transmitting the message according toa data plane protocol.
 5. The method of claim 3, wherein the messageincludes an OAM protocol data unit (PDU) according to the Y.1731standard.
 6. The method of claim 5, wherein the OAM PDU includes aclient signal fault (CSF) PDU including a type field greater than threebits specifying the first attribute or a variable length fieldspecifying the first attribute.
 7. The method of claim 3, wherein thefirst OAM protocol includes one of an OAM protocol according to IEEE802.3 or an OAM protocol according to Metro Ethernet Forum (MEF) 16; andwherein the second OAM protocol includes one of an OAM protocolaccording to IEEE 802.3 or an OAM protocol according to MEF
 16. 8. Asystem comprising: a network device comprising: a first interface toreceive a message from a second Ethernet interface, wherein the messageincludes a first attribute indicative of an Ethernet service at thesecond interface according to a first operation, administration, ormanagement (OAM) protocol; and a processor to map the first attribute toa second attribute, wherein the second attribute is in accordance with asecond OAM protocol different than the first OAM protocol, and toperform an operation at the first interface based on the secondattribute.
 9. The system of claim 8, wherein the network device is afirst network device, the system further comprising: a second networkdevice including: the second interface for transmitting the messageincluding the first attribute indicative of the Ethernet service to thesecond interface; and a processor to determine a third attribute at thesecond interface indicative of the Ethernet service at the secondinterface according to the first OAM protocol, and to map the thirdattribute to the first attribute according to an intermediate OAM map.10. The system of claim 8, wherein the processor is further configuredto encode, at the second interface, the first attribute indicative ofthe Ethernet service into the message; and wherein the second interfaceis configured to transmit the message from the second interface to thefirst interface.
 11. The system of claim 10, wherein the messageincludes an OAM protocol data unit (PDU) according to the Y.1731standard.
 12. The system of claim 10, wherein the OAM protocol includesa management plane protocol, wherein encoding and transmitting includesencoding and transmitting the message according to a data planeprotocol.
 13. The system of claim 11, wherein the OAM PDU includes aclient signal fault (CSF) PDU including a type field greater than threebits specifying the first attribute or a variable length fieldspecifying the first attribute.
 14. The system of claim 8, wherein thefirst OAM protocol includes one of an OAM protocol according to IEEE802.3 or an OAM protocol according to Metro Ethernet Forum (MEF) 16; andwherein the second OAM protocol includes one of an OAM protocolaccording to IEEE 802.3 or an OAM protocol according to MEF
 16. 15. Amethod comprising: determining, at a first Ethernet interface, a firstattribute indicative of the Ethernet service at the first interfaceaccording to a first operation, administration, or management (OAM)protocol; encoding the second attribute indicative of the Ethernetservice at the first interface into an Ethernet message; mapping thefirst attribute to a second attribute according to an intermediate OAMprotocol; and transmitting the message from the first interface to asecond interface.
 16. The method of claim 15 further comprising:receiving, in the second interface, the message, wherein the messageincludes the second attribute indicative of an Ethernet service at thefirst interface according to the second OAM protocol; mapping secondattribute to a third attribute, wherein the third attribute is inaccordance with a third OAM protocol different than the first OAMprotocol; and performing an operation at the second interface based onthe third attribute.
 17. The method of claim 16, wherein the first OAMprotocol includes one of an OAM protocol according to IEEE 802.3 or anOAM protocol according to Metro Ethernet Forum (MEF) 16; and wherein thesecond OAM protocol includes one of an OAM protocol according to IEEE802.3 or an OAM protocol according to MEF
 16. 18. The method of claim17, wherein the message includes an OAM protocol data unit (PDU)according to the Y.1731 standard.
 19. The method of claim 18, whereinthe OAM PDU includes a client signal fault (CSF) PDU including a typefield greater than three bits specifying the attribute or a variablelength field specifying the attribute.
 20. The method of claim 19,wherein the OAM protocol includes a management plane protocol, whereinencoding and transmitting includes encoding and transmitting the messageaccording to a data plane protocol.